1. Field of the Invention
This invention relates to distributed communication techniques. More particularly, this invention relates to techniques for implementing a distributed driver architecture over multiple transports. Application of this invention may especially be found in the realm of higher level protocols for IEEE 1394 systems. Further, this invention relates to bridging devices and method implementations in a distributed driver messaging system.
2. The Prior Art
The IEEE 1394 multimedia bus standard is to be the “convergence bus” bringing together the worlds of the PC and digital consumer electronics. It is readily becoming the digital interface of choice for consumer digital audio/video applications, providing a simple, low-cost and seamless plug-and-play interconnect for clusters of digital A/V devices, and it is being adopted for PCs and peripherals.
The original specification for 1394, called IEEE 1394-1995, supported data transmission speeds of 100 to 400 Mbits/second. Most consumer electronic devices available on the market have supported either 100 or 100/200 Mbits/second; meaning that plenty of headroom remains in the 1394 specification. However, as more devices are added to a system, and improvements in the quality of the A/V data (i.e., more pixels and more bits per pixel) emerge, a need for greater bandwidth has been indicated.
The 1394a specification (pending approval) offers efficiency improvements, including support for very low power, arbitration acceleration, fast reset and suspend/resume features. However, not all devices meet the 1394 specification and not all devices communicate by way of the same protocols.
The old methods for implementing distributed driver architectures provide a monolithic messaging service that is hardwired to a particular type of transport. Prior art distributed driver architectures (for example, Home Audio/Video interoperability (HAVi), and Universal Plug and Play (UPnP)) rely on a single type of transport for sending messages between distributed nodes (Function Control Protocol (FCP) in the case of HAVi, and Transmission Control Protocol/Internet Protocol (TCP/IP) in the case of UPnP). The design of these architectures is limited since they do not include provisions for multiple transport plug-ins. That is, support of multiple transports simultaneously by these architectures is not supported, even if they support 1394. Furthermore, they are proprietary in that they may only communicate with devices that can communicate with the same protocol and/or include identical connectivity media. Put another way, these technologies do not provide a means of bridging the driver control across multiple transports. Thus, an application running on a node supporting an IP transport cannot control a device residing on a node supporting FCP, even if an intermediate node supports both transports. The old method of distributing device driver control assumes a homogenous, single transport network. While old methods may support distributed control over more than one type of transport, they do not support distributed control where the controlling node resides on one transport type and the node under control resides on a second transport type.
It is therefore desirable to overcome this shortcoming by providing a means for devices to communicate with one another without regard to protocols or connectivity. This is especially true today, when users of such devices have an ever-growing desire to couple all types of audio/video equipment to their personal computers for instance. However, at present there is no convenient means for enabling multiple such devices to communicate one with the others. That is, a user may be able to connect a video camera to a computer if they have the appropriate cables and protocols. However, if that user wishes to connect an A/V system to a computer and a video camera, matters are far more difficult, if not impossible in many instances. This situation is further exasperated when available devices cannot communicate with each other due to port/media interface incompatibility.